(19) 




Best Available Copy 
EuropSlsches Patentamt 

European Patent Office 

Office europeen des brevets 



1 






(11) 



EP 0 866 403 A1 



(12) 



EUROPEAN PATENT APPLICATION 



(43) Date of publication: 

23.09.1998 Bulletin 1998/39 

(21) Application number: 98301348.3 

(22) Date of filing: 24.02.1998 



(51) Intel 6; G06F 13/10 



(84) Designated Contracting States: 

AT BE CH DE DK ES R FR GB GR IE IT LI LU MC 
NL PT SE 

Designated Extension States: 
AL LT LV MK RO SI 

(30) Prbrity: 17.03.1997 US 820470 

(71) Applicant: International Business Machines 
Corporation 

Armonk^N.Y. 10504 (US) 



(72) Inventors: 

• Mealey, Bruce Gerard 
Austin, Texas 78759 (US) 

• Swanberg, Randal Craig 
Round Rock, Texas 78664 (US) 

• Williams, Michael Stephen 
Austin, Texas 78759-4530 (US) 

(74) Representative: Moss, Robert Douglas 
IBM United Kingdom Limited 
intellectual Property Department 
Hursley Park 

Winchester Hampshire S021 2JN (GB) 



(54) Dynamic extension of static device drivers 

(57) A method of changing the functionality of a stat- 
ically bound device driver, by dynamically extending the 
static device driver using a registered driver extension. 
The static device driver has a plurality of handlers or 
functions (such as input/output functions) used to con- 
trol a device that is connected to or part of the computer 
system, and the driver extension modifies at least one 



of these functions, although it can be used to change 
several, or even all, of the functions. In the embodiment 
wherein the computer system is a UNIX-type worksta- 
tion having a kemel residing in the menrxDry, the static 
device driver is baded in the kernel and is dynamk^lly 
extended by providing at least one entry point for the 
driver extension. 
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Description 

Technical Field of the Invention 

The present invention generally relates to computer ^ 
systems and more particularly to a method for extending 
static device driver functionality without requiring re- 
building of the operating system. 

Background of the Invention 

The basic structure of a conventional computer sys- 
tem 10 is shown in Figure 1 . The heart of computer sys- 
tem 10 Is a central-processing unit (CPU) or processor 
12, which is connected to several peripheral devices, 
including input/output (I/O) devices 14 (such as a dis- 
play monitor and keyt>oard) for the user interface, a per- 
manent memory device 1 6 (such as a hard disk or floppy 
diskette) for storing the computer's operating system 
and user programs, and a temporary memory device 18 
(such as random-access memory or RAM) that is used 
by processor 12 to carry out program instructbns. Proc- 
essor 12 communicates with the peripheral devices by 
various means, including a bus 20 or a direct channel 
22. Computer system 10 may have many additional 25 
components which are not shown, such as serial and 
parallel ports for connectbn to, e.g., modems or print- 
ers. Those skilled in the art will further appreciate that 
there are other components that might be used in con- 
junctbn with those shown in the block diagram of Figure 30 
1; for example, a display adapter connected to proces- 
sor 12 might be used to control a video display monitor, 
various types of devrce drivers (software programs) are 
used to control the hardware devices. 

Computer system 10 also includes firmware 24 3S 
whose primary purpose is to seek out and load an op- 
erating system from one of the peripherals (usually per- 
manent memory device 16) whenever the computer is 
first turned on. The process of seeking out and loading 
the operating system is referred to as "booting" the com- ^ 
puter. Computer system 10 may be designed to allow 
firmware 24 to re-initialize an operating system without 
turning the computer off and back on again (a "soft" 
boot). Firmware 24 is essentially a series of machine 
instructbns which are typically stored in a read-only ^ 
storage (ROS) device, such as read-only memory 
(ROM). As shown in the flow chart of Figure 2. after 
power to computer system 10 is turned on, processor 
12 begins to execute the firmware instructions and 
seeks out an operating system (26). If an operating sys- so 
tem is found, it is toaded (28) into temporary memory 
1 8, including any device drivers present in the operating 
system image, to enable the system to communbate 
with appropriate hardware. Thereafter, additbnal device 
drivers may be dynambally loaded by the operating sys- 55 
tem (30), for example, rf a hardware device is connected 
to the computer system after the boot sequence. Finally, 
the operating system albws other application layers to 



be added, i.e.. user software programs (32). 

The foregoing descriptbn generally applies to any 
type of operating system, including two popular operat- 
ing systems known as MSDOS and UNIX (MSDOS is a 
trademark of Mbrosoft Corp.; UNIX is a trademark li- 
censed exclusively by X/Open Company Ltd.). but the 
present invention has particular application to UNIX. 
UNIX is a multi-user, multi-tasking operating system 
which is available from a variety of sources with different 
versions. These include, among others. System V from 
AT & T, AIX from IBM (AIX is a trademark of International 
Business Machines Corporatbn) and Mach from NeXT 
Computers. Figure 3 illustrates a typical UNIX worksta- 
tion 34. Workstatbn 34 includes the varbus hardware 
components shown in Figure 1. and generally repre- 
sented at 36, and furthermore includes two software lay- 
ers, the kernel 38 and the user applicatbn layer 40. Ker- 
nel 36 is the bwest level of the operating system and 
acts as the intermediary between user programs and 
hardware devbes and includes, among other things, de- 
vbe drivers that interlace with hardware control 42. Ker- 
nel 38 may include static devbe drivers 44 which are 
originally bound with the kernel during initialization and 
dynamically fc>aded device drivers 46 which are added 
to the kernel after initialization. A dynambally loaded de- 
vice driver 46 can be used for a unque devbe or can 
simply be a replacement for a generic statb devbe driv- 
er. Both types of devbe drivers are usually accessed by 
a buffering mechanism such as a devbe switch table 48. 

Device drivers are often hardware dependent, 
which can present difficulties when installing or using 
particular hardware devbes. If an appropriate devbe 
driver for a new device is not already present in the ker- 
nel, (i.e., statbally bound) and if a dynamically badable 
driver is not available, then the kernel must be re-bound 
with a new static device driver. If a dynambally loadable 
driver is available, then it can easily be baded as a ker- 
nel extension but. in some cases, the system requires 
certain devbes or hardware functions to be provided on- 
ly via static device drivers bound in the kernel since the 
facilities they require must exist prior to the ability to bad 
kernel extensions. These functions include, for exam- 
ple, NVRAM, RAMDD, and console device drivers. In 
these cases, the only way to enhance the functionality 
or capabilities of the static device driver is to rebuild the 
base kernel. Similarly, there is no way to modify a statb 
device driver once it has been toaded. For example, 
there might be a bug (software instruction error) in the 
static device driver, but it cannot be fixed unless the ker- 
nel is rebuilt. It would, therefore, be desirable and ad- 
vantageous to devise a method of changing the func- 
tionality of a statically bound device driver without re- 
quiring rebuikiing of the kernel or otherwise rebooting 
the operating system. 

Disclosure of the Invention 

i 

According to the present invention, there is provid- 
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ed a method for providing cxxitrol of a device In a com- 
puter system having memory, comprising the steps of: 
loading a static device driver into the memory of the 
computer system, the static device driver having means 
for providing a plurality of functions used to control the s 
device; the method being characterised by the further 
step of: dynamically extending the static device driver 
using a driver extension. 

According to another aspect of the invention, there 
is provided a computer system comprising: a hardware 10 
device; memory means storing a static device driver 
used to control said hardware device; processor means 
for carrying out instructions from said static device driver 
to control said hardware device; characterised in that 
the system further comprises: a device driver extension is 
registered with said static device driver such that a func- 
tion call issued to said hardware device is rerouted by 
said static device driver to said device driver extension. 

Thus, the invention provides an improved method 
of loading device drivers for a computer system which 20 
albws modification of a statically bound device driver 
without requiring rebuilding of the operating system. 

The preferred method provides control of a device 
in a computer system, generally comprising the steps of 
loading a static device driver into the memory of the 2S 
computer system, and thereafter dynamically extending 
the static device driver using a driver extension which is 
registered with the static device driver. The static device 
driver has a plurality of handlers or functions (such as 
input/output functions) used to control the device, and 50 
the driver extension modifies at least one of these func- 
tions, although it can be used to change several, or even 
all. of the functions. In the preferred embodiment where- 
in the computer system is a UNIX-type workstation hav- 
ing a kernel residing in the memory, the static device ^ 
driver is within the kernel and is dynamically extended 
by providing at least one entry point for the driver exten- 
sion. 

Brief Description of the Drawings ^0 

The invention will now be described with reference 
to a preferred embodiment thereof, as illustrated in the 
accompanying drawings, wherein: 

45 

Figure 1 is a block diagram of a prbr-art computer- 
operating system; 

Figure 2 is a flow chart illustrating how a computer 
loads a prior-art operating system with static devrce so 
drivers bound to the operating system, and then 
loads dynamically loadable device drivers after 
loading the operating system; 

Figure 3 is a block diagram of a prior art UNIX-type 55 
workstation having static and dynamk: device driv- 
ers; 



Figure 4 is a bkxk diagram of a UNIX-type work- 
statbn configured according to the present inven- 
tion with registered driver extensk)ns; and 

Figure 5 is a flow chart illustrating how. according 
to the present invention, a computer loads an oper- 
ating system with static device drivers that allow 
registration of driver extensbns, and how the statb 
drivers dynamically access the registered exten- 
sk)ns. 

Detailed Description of the Invention 

With reference now to the figures, and in particular 
with reference to Figure 4, there is deputed one em- 
bodiment 50 of a UNIX-type workstation according to 
the present inventbn. Workstation 50 is generally com- 
prised of the same basic hardware as shown in Figure 
1 , portions of whbh are indk:ated at 52, but workstatk>n 
50 has a novel operating system loaded in kernel 54 
which allows for registratkxi of static device-driver ex- 
tensk>ns. Kernel 54 has the static device drivers 56 
bound thereto, and includes conventional hardware 
control 58 that is connected to the outputs of the devbe 
drivers. Static device drivers 56 are accessed via a con- 
ventkxial-device switch table 60 that acts as an interface 
with the user applications 62. Kernel 54 also includes 
driver extensions 64 that are 'registered' with statk: de- 
vice drivers 56. The driver extensions provide control for 
hardware control 58, but are not accessed by the device 
switch table. Instead, static device drivers 56 register 
specific handlers or f unctkxis (like open, read, ioctl. or 
other I/O control functkxis) to provide process entry 
points for those functbns with respect to the particular 
devce being accessed. 

This solutk^n allows the functionality of a statk: de- 
vce driver to be dynamk:ally extended in order to get 
the flexibility of a toadable device driver in cases where 
static boot-time functionality is also required. One such 
example is that, at a later point during system initializa- 
tion, a kernel extension coukJ register its own ioctlQ han- 
dler to be called in response to an ioct!() call to that static 
devbe driver. This example could also be expanded to 
other device-driver entry points. In this manner, a user 
can change the functbn of a device driver that is stati- 
cally bound without rebinding the kemel. This adapta- 
bility allows a user to enhance a device driver, e.g., pro- 
vkJe hardware-specific differentiators, or to otherwise 
modify the driver, e.g.. fix a bug. 

The typical operatk^n of a computer system using 
registered device extensbns is shown in Figure 5. After 
power to the system is turned on (or a soft-boot com- 
mand is executed), the firmware searches for an oper- 
ating system to load (70). The operating system is then 
baded into primary memory, including any statk: device 
drivers (72). These drivers are configured to recognize 
extensk^ns based on the device driver entry points (74). 
For example, if a static NVRAM read/write device driver 
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2. A methcxi as claimed in Claim 1 wherein the static 
device driver is dynamically extended in response 
to a function call from a user application. 

5 3. A method as claimed in Claim 1 or Claim 2 wherein 
the static device driver is loaded as part of the fur- 
ther step (72) of loading an operating system on the 
computer system. 

10 4. A method as claimed in any preceding claim where- 
in: 

the computer system is a UNIX-type worksta- 
tion having a kemel (54) residing in the memo- 
?5 ry; 

the static device driver is k>aded in the kemel; 
and 

20 the static device driver is dynamically extended 

by provkJing at least one entry point for the driv- 
er extension. 

5. A method as claimed in any preceding claim where- 
of in the static device driver is dynamically extended 

by providing (74) a registratbn in the static device 
driver for the driver extension. 

6. A method as claimed in any preceding claim where- 
30 in the driver extension modifies at least one of the 

plurality of functions of the static device driver. 

7. A method as claimed in any preceding claim where- 
in the driver extension provkJes a new function for 

55 controlling the device. 

8. A method as claimed in any preceding claim where- 
in the driver extension is also loaded in the menrrary 
of the computer. 

40 

9. A method as claimed in Claim 6 wherein said at 
least one f unctk>n is an input/output functbn. 



entry point is called, the driver first checks to see if there 
are any registered extensions for that entry point and. if 
so. calls the registered extension. The extensbn can ex- 
amine the offset of the NVRAM request and determine 
if it was in the NVRAM device that it controls. If so, the 
extension would service the request, but if not, it then 
woukJ retum control to the statk: driver, whrch would call 
the next registered extenskxi or, if appropriate, handle 
the request itself. After the operating system has been 
loaded and any driver extensions have been registered, 
regular user programs are executed (76). Then, when 
any applicatk>n sends a functbn call to a static device 
driver with a registered extension, the static driver re- 
routes the call to the extension (78). In this manner, reg- 
istratkxi allows the extension to override a particular 
functbnality of. or add new functbnality to. the static 
driver. 

In one specific implementatk>n of the present inven- 
tion, an AIX operating system is nrKxiified to provide a 
machine device driver (/dev/nvram) which is a statk; de- 
vice driver provkJing the base functionality required be- 
fore it is possible to dynamically load further support. 
However, via a special extension file registered with the 
machine device driver, additional functions are provkJed 
that are nr^achine-specific. This approach altows com- 
mon static f unctbns to remain in the base operating sys- 
tem while moving machine-specific functions to appro- 
priate kemel extensbns to be dynamically loaded and 
registered with the machine device driver at run-time. 

Unlike dynamically toaded drivers, registered driver 
extensions 64 are not usually a complete driver, i.e., the 
extension usually modifies only a portkxi of the driver 
functbnality. A registered extension coub, however, 
completely replace all functbnality for a given static driv- 
er, or two or more registered extensions coukJ be used 
to overrkJe all base functbnality. Those skilled in the art 
will appreciate that an operating system constructed in 
accordance with the present inventbn can still have dy- 
namically baded drivers (not shown In Figure 4) in ad- 
ditbn to registered driver extensbns 64. 



Claims 

1. A method for providing control of a device (14) in a 
computer system (10) having memory (18), com- 
prising the step of: 



10. A method as claimed in Claim 6 wherein the static 
4S device driver is dynamically extended by registering 

the driver extension with at least one function. 

11. A computer system comprising: 
a hardware device (52); 

memory means (18) storing a statb device driv- 
er (56) used to control said hardware devbe; , 

/' 

processor means (12) for carrying out instrucr 
tions from sakJ static device driver to control 
sab hardware device; characterised in that the 
system further comprises: 



loading (72) a statb device driver (56) into the 
menrwry (1 8) of the computer system, the static 50 
device driver having means for providing a plu- 
rality of functions used to control the device; the 
method being characterised by the further step 
of: 

55 

dynambally extending (74) the statb devbe 
driver using a driver extension (64). 



7 



EP 0 866 403 A1 



a device driver extension (64) registered with 
said static device driver such that a function call 
Issued to said hardware device Is rerouted by 
said static device driver to said device driver ex- 
tension, s 

1 2. A computer system as claimed in Claim 1 1 wherein: 

said static device driver provides a plurality of 
functions for controlling said hardware device; io 
and 

said static device driver is arranged to re-route 
a function call to said device driver extensbn 
for one or more of said functions. is 

1 3. A computer system as claimed in Claim 1 1 or Claim 
12 wherein: 

the computer system is a UNIX-type worksta- 20 
tion having a kernel (54) residing in said mem- 
ory means; 

said static device driver is loaded in sakJ kernel; 
and 25 

said static device driver is arranged to re-route 
said function call by providing an entry point for 
said device driver extensbn. 

30 

14. A computer system as claimed in Claim 11 wherein 
said device driver extension provides a new func- 
tion for controlling the device. 

15. A computer system as claimed in Claim 13 wherein 35 
the kernel includes a hardware control unit (58). and 
said device driver extension interfaces directly with 
said hardware control unit. 
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